DOOR's DXL Scripting

Hi,

Is it possible to write a DXL script which will automatically make a list of all users who are not logged into database from a specified time and deactivate them.

Please post your replies
sanjaydivakarg - Tue Aug 30 08:36:31 EDT 2011

Re: DOOR's DXL Scripting
OurGuest - Tue Aug 30 09:06:53 EDT 2011

If you were looking for a faster way to get a lot of people angry at you -- this would be a very effective approach.

Re: DOOR's DXL Scripting
Mathias Mamsch - Tue Aug 30 11:33:37 EDT 2011

As OurGuest indicates with his answer you might have a bigger problem if your decision about which users shall access DOORS is only based on their last login time. However you might want to follow this approach for a big cleanup, so this would probably be a way to go.

You should evaluate the server logs to find the users that have not logged in for a long time. I think it might not be possible from DXL to find out the last login date directly.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: DOOR's DXL Scripting
llandale - Tue Aug 30 15:15:04 EDT 2011

This is very difficult. I cannot post the script. Mine is 2480 lines not counting the library, but that is perhaps 3x the size most folks would code since I like comments, lots of error checking, and bells and whistles (including 'state': Active, Warned, Disabld, Threatened, and finally Deleted).

Get a scheduled-task running on the DOORS Server that would at 12:01am every day copy the login history file into the config area where the script can read it.
You then need a rather large function that would read the login history, parse each line, and determine the last time each user logged in.
Then you can go from there.

Problems:
Disabling and Deleting users has such risk that you must be extra careful, such as making sure you did indeed get a valid Login History. If that file was deleted, it would appear that none of these users have logged in, and you would disable them all. So I have code that determines if the current history file seems an extension of the previous one.
A new user will appear to have not logged in ever.
Renamed users cause significant problems.

I thus added custom attributes to the User directory to handle all these things.

Another completely different approach would be to install a database wide post-module-open trigger that simply updated the user as "logged in right now". You could then easily write an on-demand script that read that information and took action. Yes, users would get credit for logging in only when they also opened a module (there is no 'database login' trigger).

  • Louie

I'm guessing there is a better non-DOORS FlexLM licensing solution to this.